home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 12 / Cream of the Crop 12 (Part II) / Cream of the Crop 12 (Part II).iso / BBS / SUARM21.ZIP / SUARM.DOC < prev    next >
Encoding:
Text File  |  1996-01-30  |  32.7 KB  |  728 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                         SHUT UP AND RUN THE MAIL
  8.                                     
  9.                     QWK tosser for RemoteAccess 2.50+
  10.                          and compatible systems
  11.                                     
  12.                                    By
  13.                      Michael Nelson and Pab Sungenis
  14.                                     
  15.                                Version 2.1
  16.                             30 January 1996
  17.        
  18.                                     
  19.                                     
  20.                                     
  21.                                     
  22.                                     
  23.                               ------------
  24.                               INTRODUCTION
  25.                               ------------
  26.                                     
  27.      When they say necessity is the mother of invention, they are
  28. not exaggerating.  SUARM is a perfect example of this saying
  29. translated into fact.
  30.      When my BBS, Connections!, joined the Annex network in 1994,
  31. Mike Nelson (who was then the SysOp) and I had a problem on our
  32. hands.  Despite our tinkering, jumping through hoops, and long
  33. distance phone calls to the author, we were unable to get MkNet
  34. to work under OS/2.  Since I would have rather chewed my own leg
  35. off than put the BBS back under MSDOS, I dragged out my laptop
  36. and went to work immediately.  I was fairly versed in the QWK
  37. structures (having written PabQwk, the first offline reader for
  38. an 8-bit system in 1992) and managed to have a bare-bones toss-
  39. and-scan program running in about 48 hours.  Even the name we
  40. chose (taken from a tagline we had seen) reflected the slapdash
  41. attitude behind SUARM 0.1: no bells, no whistles, nothing fancy,
  42. just shut up and run the mail.
  43.      A month later, I had finally added a few bells and whistles
  44. I had always wanted in a tosser, designed a user interface,
  45. written some quick documentation, and released SUARM upon the
  46. world.  Two quick bug fixes followed, and the program served me
  47. well.
  48.  
  49.      As time went on, some inadequacies of SUARM became apparent. 
  50. Since I had been working in a one-network-per-host situation, I
  51. hadn't seen a need for origin lines.  My 'status reports' which
  52. had been so neat at first quickly became useless and annoying. 
  53. New users had a lot of questions I didn't think would be as hard
  54. to answer as they were.  And, finally, there were just more
  55. gizmos and toys I wanted.  After nearly a year of preparation,
  56. version 2.0 of SUARM is now ready for release.
  57.      This version represents some drastic changes, unlike the
  58. quick bug fixes of 1.01 and 1.02.  Many parts of the code have
  59. been completely rewritten.  The user interface has been improved
  60. considerably.  And, best of all, the program can now work along
  61. with RA version 2.0 and higher, making configuration a breeze.
  62.      If you have never used SUARM before, you are in for a treat. 
  63. If you've used a previous version, you might be able to get away
  64. with just reading the CHANGES.DOC file included in the archive,
  65. but I suggest you stick around to see some of the new additions
  66. up close.
  67.  
  68.  
  69.                                 ---------
  70.                                 IN THEORY
  71.                                 ---------
  72.                                     
  73.      QWK networking really began with the founding of what is now
  74. the ILink[sm] computer network.  The concept grew out of Mark
  75. "Sparky" Herring's QWK offline mail format, which had allowed
  76. users to download new messages, read them offline, and upload
  77. replies.  It seemed a logical next step to take one of those mail
  78. packets and import the messages into another board.
  79.      The fundamental principles of QWK networking have not
  80. changed since the first transfers took place.  A system calls
  81. another system, downloads a mail packet, and imports it into its
  82. own messages bases.  New messages are scanned, packed, and sent
  83. as a reply packet.  While not as elegant as other methods, QWK
  84. networks have the advantage of being easy to set up and (for the
  85. end user) easy to maintain.
  86.      SUARM implements a number of 'additions' that have crept
  87. into QWK over the years, most notably the 'kludge' lines.  While
  88. QWK headers originally only allowed 25 characters for a user name
  89. or subject line, the 'kludge' lines have expanded this limit to
  90. 60.  SUARM can use these add-ons and other modifications to the
  91. format to provide the best interface between RemoteAccess (and
  92. similar systems) and QWK networks available today.
  93.  
  94.  
  95.                               -------------
  96.                               SETTING IT UP
  97.                               -------------
  98.                                     
  99.      If you are installing SUARM for the first time, extract it
  100. into its own directory.  You may also want to add this directory
  101. to your search path, and add a SUARM environment variable
  102. pointing to this directory.  If you are upgrading from version
  103. 1.x, simply extract the new version on top of your old version. 
  104. SUARM and SUARMCFG will make all needed changes to your
  105. configuration automatically.
  106.      Once you have extracted the program, pick up a mail packet
  107. from each BBS you are going to be importing from.  You will need
  108. a packet from each BBS you hope to use SUARM with.
  109.      Once you have all the packets you need, run the program
  110. SUARMCFG.EXE.  This program will allow you to set up your system
  111. in the simplest possible manner.  (Those wishing to experiment,
  112. to get the most power possible from SUARM, should also read
  113. Appendix A on configuration file structures.)
  114.      You will see three options on the menu bar.  Select "Edit." 
  115. From the pull-down menu, select "pathnames."  You will be
  116. prompted for three paths: where to find incoming QWK packets,
  117. where to put outgoing REP packets, and a scratch directory where
  118. SUARM may do its work.
  119.  
  120.                                 WARNINGS
  121.                                     
  122.            ALL three paths must be defined before continuing.
  123.             Make sure NO important files are in SUARM's work
  124.                   directory.  SUARM will delete them.
  125.                                     
  126.      Once you have set up these paths, select "BBS" from the menu
  127. bar.  From the pull-down menu, select "New."  You will be
  128. prompted for the BBS ID of the board you wish to add to the
  129. configuration.  Type the filename of the QWK packet (minus the
  130. extension) of the appropriate board.  SUARM will scan the packet,
  131. configuring itself for that BBS.  You should then save both the
  132. main configuration and the config for that BBS by pressing F6 and
  133. then F8.  After this, you can continue to add as many "New"
  134. boards as you want.
  135.      Once all the BBS's you will be using have been added to
  136. SUARM's databases, you are ready to configure SUARM to import and
  137. export from each.
  138.  
  139.  
  140.                      ------------------------------
  141.                      USING THE CONFIGURATION EDITOR
  142.                      ------------------------------
  143.                                     
  144.      To load the configuration editor, type SUARMCFG from the DOS
  145. prompt.  If you have set the SUARM environment variable, the
  146. editor will change to the SUARM directory immediately.
  147.      The editor will look for a file called SUARM.CFG, and load
  148. it if it is found.  This is the main configuration file,
  149. containing important information about your system setup.  If no
  150. SUARM.CFG is found, the editor will use several default settings. 
  151. Chances are you will want to change them.
  152.      At any time, you may press F5 to re-load SUARM.CFG from
  153. disk, or F6 to save the values you have set up.  You may also
  154. press F7 to load a .CFG file for a BBS, or F8 to save the current
  155. BBS's .CFG at any time.  This and other important hotkeys are
  156. displayed on the bottom line of the screen.
  157.      Across the top of the screen are the main menus for the
  158. editor.  From left to right, they are:
  159.  
  160.      FILE: This menu has only two options.
  161.  
  162.           CHANGE DIRECTORY: This allows you to change the current
  163.           working directory.  You may have to use this if you did
  164.           not set the SUARM environment variable, or if you want
  165.           to work on a configuration saved in a different
  166.           direcory.
  167.  
  168.           EXIT: Exit the editor.
  169.  
  170.      EDIT: This menu allows you to change important settings,
  171.      which will generally be used by the tosser at all times
  172.      (although many options can be overriden by a custom .CFG
  173.      file for a BBS, see Appendix A).
  174.  
  175.           SYSOP: These settings control how the tosser interacts
  176.           with you personally, and how it handles functions
  177.           directly related to you.  The settings under this menu
  178.           are:
  179.  
  180.                SYSOP NAME: This is your name, as defined in your
  181.                BBS setup.  All imported files and other important
  182.                messages are addressed to this name.  Also, any
  183.                messages addressed to "SysOp" or from "SysOp" on
  184.                your system can be converted to this name.  See
  185.                "Convert Outgoing" below.
  186.  
  187.                HUB SYSOP NAME: This is the name of the SysOp of
  188.                your hub.  If you select the "Convert Incoming"
  189.                option (see below), all messages to/from "SysOp"
  190.                in your mail packet will be changed to this name. 
  191.                This name will be different for each system, and
  192.                as a result is not saved in SUARM.CFG, but in the
  193.                individual BBS's .CFG.
  194.  
  195.                IMPORT BASE ID: This is the base ID (see below) to
  196.                import all specified text files to.  Whether or
  197.                not you import text files, this base MUST be
  198.                defined.  The default is base #1 as defined in
  199.                MESSAGES.RA.
  200.  
  201.                CONVERT INCOMING: If this option is enabled, then
  202.                all messages coming into your system to or from
  203.                "SysOp" will have that name changed to the Hub
  204.                SysOp name.
  205.  
  206.                CONVERT OUTGOING: This option allows you to change
  207.                all messages to/from "SysOp" exported from your
  208.                system so they bear your name instead.
  209.  
  210.                KILL DUPLICATE MESSAGES: When this option is
  211.                turned on, SUARM will check its database to
  212.                determine whether or not each message in a packet
  213.                has already been imported.  This is effective in
  214.                stopping 'dupe loops' and 'carpet bomb' messages. 
  215.                If you do not want or need this option, turning it
  216.                off will increase the speed of the program when
  217.                tossing.  It is recommended you leave it ON.
  218.  
  219.           PATHS: This lets you define the paths SUARM is to use
  220.           for incoming QWKs, outgoing REPs, and as a scratch
  221.           workspace for its own use.  You should have already
  222.           defined these in the previous section.
  223.  
  224.           ARCHIVERS: This allows you to define the command line
  225.           to be used for each of the four archivers supported by
  226.           SUARM.  The default settings are the recommended
  227.           command lines for use with PKZIP, ARJ, PKPAK/PKARC, and
  228.           RAR.  They may be edited to suit your needs (for
  229.           example, if you use InfoZIP instead of PKZIP, or want
  230.           different default settings for RAR).
  231.                NOTE: if your network uses FWKED-style packet
  232.           encryption (see below, and also appendix B) and you
  233.           configure SUARM to automatically decrypt the packet,
  234.           the 'Unzip' command will be ignored at the decryption
  235.           stage, since FWKED only works under PKZIP, and requires
  236.           a custom command line.
  237.      
  238.           There are also options to LOAD and SAVE the SUARM.CFG
  239.           file.
  240.  
  241.      BBS: This menu is the largest, and lets you configure the
  242.      settings for the current board.  Before any of these options
  243.      can be used, you must first either LOAD a BBS configuration,
  244.      or create a NEW one from a mail packet.
  245.  
  246.           CONFERENCES: This is the most important part of the
  247.           configuration, and where you will spend the most time. 
  248.           You can also get to this section by pressing F4 at any
  249.           time.
  250.                You will see a window with your currently defined
  251.           conferences (if you are just beginning your
  252.           configuration, this window will be empty.)  You may
  253.           move up and down the conferences with the arrow keys. 
  254.           Buttons on the side of the window allow you to edit or
  255.           delete conference selections, add a new selection, and
  256.           exit from the conference editor.  
  257.                When you add or edit a conference, you will see a
  258.           dialog box.  You will be prompted for:
  259.  
  260.                BASE ID: With RA 2.02 or greater, this will
  261.                usually be a conference number as defined in
  262.                MESSAGES.RA.  Under other systems, or in certain
  263.                cases, this will be an 'MK' style base ID.  See
  264.                below for details on MK IDs.
  265.  
  266.                CONFERENCE: This is the conference to import from
  267.                your hub.  You will be able to select zfrom a menu
  268.                of available conferences with the arrow keys.
  269.  
  270.                ORIGIN: This allows you to select which pair of
  271.                origin lines (see below) will be used for this
  272.                conference.  Up to five pairs of origins may be
  273.                defined for each BBS you get mail from, allowing
  274.                you to import several different networks at the
  275.                same packet for each BBS.
  276.  
  277.                When you have finished configuring the conference,
  278.           hit ENTER or press OK.  To abort at any time, hit ESC
  279.           or press "Cancel."
  280.  
  281.           BAD MESSAGES: A relatively new concept in QWK
  282.           networking, bad messages are (basically) stuff you
  283.           weren't expecting.  If you turn on a conference in the
  284.           mail door of your hub and download it, but don't add it
  285.           to your configuration in SUARM, the tosser won't know
  286.           what to do with it.  Thus, it is considered a 'bad
  287.           message.'
  288.                This section offers you three options for handling
  289.           bad messages:
  290.  
  291.                IGNORE them, just skip over them when tossing.
  292.                
  293.                DUMP them to a specified base.  The message will
  294.                be saved, along with some basic information, in
  295.                this base.  If you have configured to save your
  296.                bad messages in this manner, SUARM will scan
  297.                through your bad base each time it is run to see
  298.                if the conference in question has been configured
  299.                yet.  If it has, then SUARM will automatically
  300.                move the messages into that conference.
  301.  
  302.                AUTO-JAM them.  This creates a JAM format message
  303.                base for the conference, based upon the name it is
  304.                given on your hub.  A future version will also
  305.                allow automatic updates to MESSAGES.RA for auto-
  306.                JAMmed bases.  This allows you to keep the
  307.                conference separate, and ready to be added to your
  308.                BBS at your leisure.
  309.  
  310.                You will also be asked for:
  311.  
  312.                BAD BASE ID: The base ID (see below) of the
  313.                conference to dump bad messages in.  If you do not
  314.                have bad messages set to "dump," then this will be
  315.                ignored.
  316.  
  317.                AUTO-JAM PATH: The path to put all automatically
  318.                created JAMbases in.  If you do not have bad
  319.                messages set to "Auto-JAM" then this will be
  320.                ignored.
  321.  
  322.           ORIGIN LINES: This section lets you define the origin
  323.           lines that will be appended to mesages leaving your
  324.           system, and on messages that originate (without an
  325.           origin line of their own) from your hub.  Up to five
  326.           pairs of origin lines may be defined for each BBS, and
  327.           each conference can be configured to use any of the
  328.           five pairs.
  329.                Note that origin lines, like nuns, policemen, and
  330.           Krynoids, always travel in twos.  You should make sure
  331.           that each origin line is a matched pair.  (For example,
  332.           if you have your origin #1 mentioning ILink, you don't
  333.           want your hub's origin #1 mentioning GeniusNet.)
  334.                Many networks have standard layouts and content
  335.           requirements for origin lines.  Make sure you check
  336.           with your network administration or with network rules
  337.           when you enter your origin lines.  
  338.  
  339.           OPTIONS: These are some different options, not
  340.           important enough to warrant their own menu option, but
  341.           too important to ignore.
  342.                The options available in this section are:
  343.  
  344.                CONVERT NAMES TO UPPERCASE: Some mail doors (and
  345.                some networks) require that the "To" and "From"
  346.                line on each message be in uppercase.  RA uses
  347.                mixed-case as a standard.  If you select this
  348.                option, SUARM will automatically convert the names
  349.                on all messages exported from your board to your
  350.                hub to uppercase.  The default is NOT to do this.
  351.  
  352.                MAXIMUM NUMBER OF DUPES: This allows you to
  353.                control the size of SUARM's duplicate database. 
  354.                Each dupe record takes 6 bytes of disk space, so a
  355.                database of 10000 (the default) duplicate records
  356.                would require 60000 bytes.  If disk space is at a
  357.                premium, you may lower this number.  (Lowering the
  358.                number also slightly increases tossing speed, but
  359.                at the expense of accuracy.)
  360.                     Note that this is a GENERAL option, and will
  361.                be saved in SUARM.CFG, not the BBS's .CFG.
  362.  
  363.                REPLY COMPRESSION: You may select the compression
  364.                format to be used on outgoing .REP packets to your
  365.                hub.  This has no affect on incoming mail packets;
  366.                SUARM automatically detects the compression format
  367.                used.  SUARM supports PKZIP, ARJ, PKPAK/ARC, and
  368.                RAR compression formats.
  369.  
  370.           IMPORT TEXT FILES: This allows you to define a number
  371.           of text files to be imported if they are included in
  372.           your mail packet.  For example, a SESSION.TXT file may
  373.           be imported with a complete rundown on mail traffic for
  374.           that packet, or an important news file or bulletin
  375.           included in the packet can be imported as mail to you. 
  376.           All imported files are saved in the base specified
  377.           under the "SysOp" menu option, with the file name as
  378.           the subject.
  379.  
  380.  
  381.           ENCRYPTED MAIL: For systems receiving encrypted mail
  382.           packets by satellite, SUARM implements the FWKED
  383.           (CODEKEYS.LST/KEY_ID) standard for automatic
  384.           decryption.  Make sure your CODEKEYS.LST is in the
  385.           SUARM directory if you enable this option.
  386.                You will be prompted for:
  387.  
  388.                ENCRYPTED MAIL PATH: This is the path your
  389.                encrypted mail packets will be found in.  It will
  390.                almost always be different from your normal .QWK
  391.                path.
  392.  
  393.                ENCRPYTED MAIL MASK: This is the filemask to
  394.                search for packets with.  For example, if you are
  395.                receiving encrypted ILink packets, the filemask
  396.                will be ILINK.0*.  Encrypted packets from my
  397.                system would be CNX.0*.
  398.  
  399.                The general rule of thumb is: if you don't know
  400.           whether or not you need this, then you don't need it. 
  401.           Check with your network administration if you are not
  402.           sure.
  403.                More about encrypted packets in Appendix B.
  404.  
  405.           REFRESH CONFERENCE NAMES: Often, names will change on a
  406.           system, and conferences will be added and dropped. 
  407.           This option allows you to update SUARM's "Conference
  408.           name" database for a specific hub.  You will need a
  409.           mail packet in the .QWK path for the hub you want to
  410.           update.
  411.  
  412.           NEW: This allows you to create a NEW BBS configuration,
  413.           and is usually used when you are picking up mail from a
  414.           new system.  You should have already used this option
  415.           when first setting up.  You will be prompted for the
  416.           BBS ID of the hub in question, and the rest will be
  417.           done automatically.
  418.  
  419.           There are also options to LOAD and SAVE that BBS's .CFG
  420.           file.
  421.  
  422.  
  423.                             ---------------
  424.                             ABOUT BASE ID'S
  425.                             ---------------
  426.  
  427.      If you are using SUARM with RA 2.02, then generally the
  428. "base ID" you are entering for each conference and for other
  429. situations (saving bad messages, importing text files, etc.) will
  430. simply be the conference number as you have it defined in
  431. MESSAGES.RA.  For example, if you give "145" as the base ID of a
  432. conference you are importing, then all messages in that
  433. conference will be imported into message base number 145 on your
  434. BBS.  This works with both Hudson and JAM message base types, and
  435. allows you to set up SUARM in the simplest possible manner and
  436. the shortest possible time.
  437.      There are times, however, when this is not good enough.  For
  438. example, you may be running a BBS program other than
  439. RemoteAccess, or you may want to import messages into a base not
  440. defined in MESSAGES.RA (for example, a *.MSG-format netmail base,
  441. or as part of a doubled-Hudson setup).  For these cases, SUARM
  442. provides a simple method of directly addressing a message base's
  443. format and location on your drives.
  444.      SUARM supports what is known as the 'MK' base ID format,
  445. named after MKNet and the MK message utilities which first used
  446. it.  It is especially included for those making the transition
  447. from MKNet to SUARM.  An MK base ID is a single letter denoting
  448. the message base's format followed by (if needed) a sub-board
  449. number and the location of the base on disk.
  450.      Formats supported in SUARM 2.0 are:
  451.  
  452.           HUDSON: (Also known as QBBS).  H followed by a three
  453.           digit board number and the path to your Hudson base.
  454.  
  455.                Example: H001C:\RA\MSGS\
  456.  
  457.           JAM: J followed by the JAMbase path and name.
  458.  
  459.                Example: JE:\RA\MSGS\JAM\RAUTIL
  460.  
  461.           SQUISH: S followed by the SquishBase path and name.
  462.  
  463.                Example: SC:\PROBOARD\MSGS\FIDO_OS2
  464.  
  465.           *.MSG: ("Fido")  F followed by the path of the base.
  466.  
  467.                Example: FC:\IM\NETMAIL\
  468.  
  469.  
  470.                             -----------------
  471.                             ADVANCED CONCEPTS
  472.                             -----------------
  473.                                     
  474.      SUARM's configuration files were designed to be easy to
  475. read, understand, and edit.  In fact, they are simple text files
  476. issuing a number of commands.  (The exact command names and
  477. syntax are covered in Appendix A.)  SUARM will recognize a
  478. command whether it is in the master SUARM.CFG, or in the
  479. configuration file of a BBS.  This allows you to tailor your
  480. setup to your specific needs, instead of making you use the
  481. 'bigger hammer' method of forcing things into place.
  482.      For example, you can change global definitions on a
  483. temporary basis by adding the appropriate command in a BBS's .CFG
  484. file.  Let's say that for some reason, your hub 'FUNBBS' is still
  485. using PKZIP 1.0, and you need to change your ZIP command for that
  486. BBS only to make sure your REPs are readable by your hub.  You
  487. could add a line to your FUNBBS.CFG:
  488.  
  489.      ZIP=PKZIP10.EXE -a,PKUNZIP -o
  490.  
  491. This would make SUARM use PKZIP10.EXE instead of your standard
  492. PKZIP when you compress your replies.
  493.      Or, for example, say you want to check for duplicates in
  494. general, but not from one specific BBS.  You could add the line
  495. to that BBS's .CFG:
  496.  
  497.      DUPECHECK=OFF
  498.  
  499.      I refer to this concept as 'overriding.'  Essentially, you
  500. are overriding your master configuration, telling SUARM to do
  501. things differently in this one case.
  502.  
  503.      In the same way, you can take a function normally associated
  504. with a specific BBS and make it apply to ALL boards you feed from
  505. simply by including it in your SUARM.CFG file.  For example:
  506. adding the line:
  507.  
  508.      OPTION=UPPERCASE
  509.  
  510. to SUARM.CFG will make sure ALL reply packets, regardless of
  511. where they are going, use uppercase-only names in their headers. 
  512. Or adding:
  513.  
  514.      IMPORT=SESSION.TXT
  515.  
  516. will import the SESSION.TXT files of all packets that pass
  517. through SUARM.
  518.      This concept is called 'globalizing,' since you are taking
  519. an option and forcing SUARM to apply it globally.  ALSO NOTE that
  520. you CAN, if for some reason you want to, override a globalized
  521. command.  The individual BBS's .CFG file always has final say, so
  522. be careful with overriding and globalizing, or you might end up
  523. not doing what you wanted to.
  524.      Also note that SUARMCFG.EXE always creates the optimal
  525. configuration file for your system, and as a result ignores all
  526. globalizing and overriding.  If you modify your .CFG files in
  527. this manner, I suggest that you NOT use SUARMCFG.EXE.
  528.  
  529.  
  530.                               -------------
  531.                               IN CONCLUSION
  532.                               -------------
  533.                                     
  534.      This new version of SUARM has been as much a labor of love
  535. as it has an update to suit my needs and the needs of others.  A
  536. lot of bug fixes have been made and a lot of new 'gizmos' as one
  537. user called them have been added at people's prompting.
  538.      Briefly, let me thank Jim Lee, Michael Leavitt, Patrick
  539. Spreng, Kathy Lessa, Richard Sharp, Pete Rocca, and everyone else
  540. who has made contributions to this version of SUARM.  Especially
  541. all the intrepid beta testers out there.  Also, thanks to Fred
  542. Kantor for creating an encryption system that was not only easy
  543. to use as a SysOp, but easy to implement into my own software.
  544.      To contact me, netmail me at 1:266/73, E-Mail me at
  545. pab@cnx.com.  I also monitor the Fidonet RAUTIL echo and most
  546. conferences on ILink for personal mail to me.
  547.      I also offer a Fidonet echo called EMPIRE for product
  548. support for SUARM, Bulkmail, Lyme, and my other programs.  It's
  549. also available as an Internet mailing list.  For information on
  550. connecting to either, please contact me.
  551.      And don't forget to register!
  552.  
  553.                                    Pab Sungenis - 6 Aug 1995
  554.  
  555.  
  556.                  --------------------------------------
  557.                  APPENDIX A: CONFIGURATION FILE LAYOUTS
  558.                  --------------------------------------
  559.  
  560.                             FILE: SUARM.CFG
  561.               
  562. Purpose: Main configuration file, determines global configuration.
  563. Format:  One command per line.
  564.  
  565.  
  566.                            FILE: bbsname.CFG
  567.              
  568. Purpose: Configuration for import from a BBS, determines settings
  569.          for that BBS only.
  570. Format:  One command per line.
  571.  
  572.                            FILE: bbsname.CNF
  573.              
  574. Purpose: Holds conference names for all available conferences from a hub.
  575.          Created by SUARMCFG's "New" BBS command.
  576. Format:  First line: number of available conferences (decimal).
  577.          Subsequent lines: Conference number (decimal), space, conference
  578.          name.
  579.  
  580.                           AVAILABLE COMMANDS:
  581.             
  582. Command:  ;
  583. Syntax:   None.
  584. Purpose:  Designates a comment line.
  585.  
  586. Command:  ORIGIN
  587. Syntax:   ORIGIN=num,text
  588. Purpose:  Specifies text for origin line number "num."
  589.  
  590. Command:  OPTION
  591. Syntax:   OPTION={ZIP|PAK|ARJ|RAR}
  592. Purpose:  Specifies which compression format to use on outgoing
  593.           messages
  594.  
  595. Command:  OPTION=UPPERCASE
  596. Syntax:   OPTION=UPPERCASE
  597. Purpose:  Converts names in headers of outgoing messages to
  598.           uppercase.  Default is mixed case.
  599.  
  600. Command:  HUBORIGIN
  601. Syntax:   HUBORIGIN=[num,]text
  602. Purpose:  Specifies text for hub origin line number "num."  If
  603.           no number is specifed, defaults to Hub Origin #1 (for
  604.           compatibility with SUARM 1.x).
  605.  
  606. Command:  MAXDUPES
  607. Syntax:   MAXDUPES=num
  608. Scope:    Global only.
  609. Purpose:  Sets the maximum number of duplicate records to 'num'
  610.           where 0 < num <= 10000
  611.  
  612. Command:  WORKPATH
  613. Syntax:   WORKPATH=pathname
  614. Purpose:  Defines the path SUARM will use for temporary storage.
  615.           Note that the pathname MUST end in a \, and the path
  616.           cannot be used for anything else, since SUARM will wipe
  617.           it.
  618.  
  619. Command:  QWKPATH
  620. Syntax:   QWKPATH=pathname
  621. Purpose:  Defines the path SUARM will search for mail packerts.
  622.           Note that the pathname MUST end in a \.
  623.  
  624. Command:  REPPATH
  625. Syntax:   REPPATH=pathname
  626. Purpose:  Defines the path SUARM will place reply packets.  Note
  627.           that the pathname MUST end in a \.
  628.  
  629. Command:  ENCRYPT
  630. Syntax:   ENCRYPT={YES|NO},pathname,filemask
  631. Purpose:  Defines encryption settings.  If auto-decrypt
  632.           (ENCRYPT=YES) is enabled, then instead of the QWKPATH
  633.           defined above, SUARM will search the specified path for
  634.           files matching the specified filemask, decrypt them,
  635.           and toss them.
  636.  
  637. Commands: ZIP, RAR, ARJ, PAK
  638. Syntax:   (command)=compresscommand,decompresscommand
  639. Purpose:  Defines the command lines to be used for the specified
  640.           compression format.  Generic command lines are created
  641.           by both SUARM and SUARMCFG, but this allows you to
  642.           specify different options or compression programs for       
  643.           each format.
  644.  
  645.  
  646. Command:  KEEPBAD
  647. Syntax:   KEEPBAD=baseid
  648. Purpose:  Defines the base to keep bad messages in, if BADTYPE is
  649.           set to KEEP.
  650.  
  651. Command:  BADTYPE
  652. Syntax:   BADTYPE={KEEP|IGNORE|AUTO}[,pathname]
  653. Purpose:  Specifies handling of bad messages; whether they are
  654.           kept in a bad message base, ignored, or a base is
  655.           automatically created (in path "pathname").
  656.  
  657. Command:  CNV
  658. Syntax:   CNV={IN|OUT},{YES|NO}
  659. Purpose:  Enables/disables conversion of "SysOp" on messages to       
  660.           the appropriate SysOp name.
  661.  
  662. Command:  FILEIMPORT
  663. Syntax:   FILEIMPORT=baseid
  664. Purpose:  Specifies the Base ID to import text files into.  MUST
  665.           be defined, whether used or not.
  666. Note:     Replaces STATID from SUARM 1.x config files.  STATID
  667.           lines will be used/converted automatically.
  668.  
  669. Command:  NAME
  670. Syntax:   NAME=sysopname[,hubsysopname]
  671. Purpose:  Defines SysOp name, and (optionally) the name of your
  672.           hub's SysOp.
  673.  
  674. Command:  DUPECHECK
  675. Syntax:   DUPECHECK={ON|OFF}
  676. Purpose:  Enables/disables duplicate message checking.
  677.  
  678. Command:  IMPORT
  679. Syntax:   IMPORT=filespec
  680. Purpose:  Import specified text file if included in packet.
  681.  
  682. Command:  (conference number)
  683. Syntax:   num=baseid
  684. Purpose:  Import messages from conference number "num" on your
  685.           hub into the specified base ID.  This defines the
  686.           mapping used to import a packet.
  687.  
  688.  
  689.                        --------------------------
  690.                        APPENDIX B: ENCRYPTED MAIL
  691.                        --------------------------
  692.  
  693.      With the advent of satellite mail delivery, some QWK
  694. networks are opting to encrypt their mail packets when they are
  695. sent over the satellite.  This way, only people with valid keys
  696. (presumably network SysOps) will be able to decode and import the
  697. mail, preventing 'renegade' boards from echoing networks they are
  698. not members of.
  699.      SUARM implements one popular method of packet decryption:
  700. the FWKED method.  This method, created by programmer Fred
  701. Kantor, matches up a keyspec in an encrypted packet with the
  702. appropriate decryption key in a file known as CODEKEYS.LST.  The
  703. packet is then decoded, using the specified key.  This method was
  704. recently approved and implemented by the ILink network for their
  705. mail delivery over the Planet Connect satellite service and an
  706. upcoming FTP delivery method.  Other networks will probably
  707. follow suit in the upcoming months.
  708.      If you need packet decryption, obtain the appropriate
  709. CODEKEYS.LST file from your network administration.  Place this
  710. file in your SUARM directory, then select the 'Encryption' option
  711. under the 'BBS' menu in SUARMCFG.
  712.  
  713.      ENABLE AUTO-DECRYPTION: Check this box to activate the
  714. automatic decryption.  Note that if this box is checked, SUARM
  715. will only look for encrypted mail packets from that BBS.
  716.  
  717.      ENCRYPTED PACKET PATH: Enter the path to search for
  718. encrypted packets.  This will usually be the directory your
  719. satellite receiving program stores them in.
  720.  
  721.      ENCRYPTED PACKET MASK: This is the filemask to use when
  722. searching for encrypted packets.  For ILink packets, use
  723. ILINK.0*.
  724.  
  725.      SUARM's built-in decryption enables you to save a step in
  726. your mail tossing.  You will not need the FWKED program, nor will
  727. you need to pre-process your packets before tossing them.
  728.